@adnanademovic: it'd be great if you could review, merge & release this and then bump rosrust to the new release as that'd resolve security alerts (reported e.g. by dependabot) on rosrust & its downstream consumers.

this is also a good reason to not combine that release with switching to async: rosrust as the main (only?) consumer of this crate isn't async either (and it doesn't make sense to invest the time to make it async anymore seeing that ROS 1 will be EOL very soon)

i noticed a problem with this several layers further up: when used within an async context (as e.g. in this ros-core-rs example) then this crashes in debug builds due to this check and i now realised that the reqwest docs even state:

Conversely, the functionality in reqwest::blocking must not be executed within an async runtime, or it will panic when attempting to block. [..]
If the immediate context is only synchronous, but a transitive caller is async, consider changing that caller to use tokio::task::spawn_blocking around the calls that need to block.

the suggestion works, but it does mean that users of rosrust must wrap calls to it from async code in tokio::task::spawn_blocking (which, one might argue, they might've already had to do since it's sync code).

thus, a call like this:

rosrust::loop_init("talker_listener", 1000);

becomes:

    tokio::task::spawn_blocking(|| {
        rosrust::loop_init("talker_listener", 1000);
    })
    .await?;

in the linked ros-core-rs example the same has to be done for rosrust::shutdown - everything else is already being executed in a blocking context (it already uses tokio::task::spawn_blocking for the talker & listener).

i do believe that this is still the correct thing to do (hyper v1 is also async, so either way you'll run into this)